22 实践课-工业级 AI 智能体架构设计
工业级 AI 智能体架构设计
关联:索引
术语小抄(初学者版)
-
架构(Architecture):系统的模块划分、连接方式、数据流与关键约束(性能/安全/可追溯)。
-
模块边界(Boundary):这个模块做什么/不做什么,避免职责漂移。
-
接口契约(Contract):输入字段、输出字段、错误码、幂等/超时/重试、审计追踪字段等约定。
-
架构图(Architecture Diagram):用图把“模块 + 关系 + 数据/控制流 + 约束”说清楚,不只是画框。
-
数据流(Data Flow):数据从哪里来,怎么被处理,去哪里,如何回放与复现。
-
标注数据(Labeled Data):为训练/评估提供的“带答案的数据”,在工业场景必须可追溯、可审计、可复用。
-
先修:已学习 02(核心概念)与 07(智能体原理),并完成至少 1 次工具开发或工具链实践(13–20 任一均可)。
-
环境:Python 3.10/3.11(与 01 口径一致)。
作业:布置(见文末)
1)工业级智能体的三段式不是“概念”,是“可交付模块”
- 感知层:把多源输入变成结构化状态(可校验、可追溯)。
- 决策层:把状态路由为动作(可解释、可测试、可回放)。
- 执行层:把动作变成系统操作(可控、可审计、可回执)。
2)所有模块接口必须回答 6 个问题(接口六问)
- 输入字段是什么?哪些必填?哪些可选?范围/枚举是什么?
- 输出字段是什么?成功/失败分别长什么样?
- 失败语义是什么?(错误码、是否可重试、是否需要人工介入)
- 超时/重试策略是什么?(谁负责重试?最多几次?退避策略?)
- 幂等性如何保证?(同一个请求重复执行会不会造成副作用)
- 如何追踪与审计?(trace_id、request_id、事件日志、回执)
3)架构图最小信息集(画图不跑偏)
一张合格的架构图至少包含:
- 模块:感知/决策/执行(可再细分)
- 连接:数据流(结构化数据)、控制流(动作调用)
- 外部系统:传感器/数据库/ROS2/日志系统(以“系统边界线”区分内外)
- 关键约束:权限/安全门禁、失败兜底、审计与回放入口
AI 工具使用:架构初稿生成 / 接口契约优化 / 架构图审计(学生可直接复制)
使用方法:把你们的“场景描述、已知数据源、执行系统、规则约束、风险点”粘贴到
{你的内容}。要求 AI 先产出结构化清单,再产出图和契约表。你必须进行人工审计与回归校验,不可直接照搬。
模板目录:
- 模板 1:生成工业级智能体架构原则思维导图(输出为清单)
- 模板 2:生成分拣场景三段式架构图(Mermaid)
- 模板 3:生成模块接口契约表(可落地、可测试)
- 模板 4:审计与改进学生架构图(指出接口问题与改进建议)
模板 1:工业级智能体架构原则思维导图(清单版)
你是工业级AI智能体架构师。请围绕“感知-决策-执行”架构,输出一份可教学的思维导图(用分级清单表示,不要画图),必须包含:
1)模块划分原则(边界、职责、可替换性)
2)接口设计原则(输入输出契约、错误语义、trace_id、幂等与重试)
3)可靠性原则(降级、兜底、人工接管、回放)
4)安全与合规(最小权限、审计、敏感数据处理)
5)绿色制造视角(节能减耗、效率提升、避免无效调用/空转)
输出要求:
- 只输出<<<MINDMAP>>>...<<<END_MINDMAP>>>,用最多4层缩进。
我的材料:{你的内容}
解释与自检:
- 这条模板用于把“架构原则”变成一份可复用的检查表,后续会用来审计你们的架构图与接口表。
模板 2:分拣场景三段式架构图(Mermaid)
你是分拣场景智能体架构设计师。请基于我的材料输出一个 Mermaid flowchart 架构图,必须包含:
- 感知层:分拣数据采集、指令解析、数据校验与归一化
- 决策层:意图识别、规则匹配、任务规划/路由、澄清/二次确认、异常处理
- 执行层:任务下发、设备控制(机械臂/输送线)、执行回执、状态查询
- 横切能力:权限与安全门禁、审计日志、可观测性(trace_id贯穿)、回放与复盘入口
输出要求:
- 只输出<<<MERMAID>>>...<<<END_MERMAID>>>,不要解释文字。
我的材料:{你的内容}
解释与自检:
- 生成图之后,你们要检查“是否画清楚了系统边界”,以及“是否把横切能力画成可用模块/服务而不是一句话”。
模板 3:模块接口契约表(可落地、可测试)
你是智能体落地工程师。请为“分拣场景智能体”的感知/决策/执行三个层级输出接口契约表(Markdown表格),列必须包含:
模块 | 子模块 | 输入(字段:类型/约束) | 输出(字段:类型) | 失败返回(错误码/是否可重试) | 幂等与超时 | 审计字段(trace_id等)
要求:
1)每层至少2个子模块;
2)字段要可校验(枚举/范围/必填/可选写清楚);
3)失败返回要工程化(不要只写“失败”);
4)至少给出3条“常见异常”并说明落在哪个模块处理最合适。
材料:{你的内容}
解释与自检:
- 契约表输出后,把每个“失败返回”对照 07/19 的统一口径:必须结构化、可追溯、可回放。
模板 4:审计与改进学生架构图(接口问题导向)
你是课堂项目的技术评审。下面是一份学生的“智能体架构图(文字描述版)+ 接口表(简版)”。请输出:
1)<<<ISSUES>>>:按严重度排序的问题清单(每条说明影响:会导致什么故障/越权/不可测试)
2)<<<PATCHES>>>:最小改动建议(能直接替换进文档的句子/表格行)
3)<<<CHECKLIST>>>:回归验证清单(至少8条,包含缺信息、冲突、注入干扰、执行超时、设备回执丢失、权限不足)
输出要求:
- 三段格式必须严格包含ISSUES/PATCHES/CHECKLIST标记;
- 不要输出长段散文。
材料:{你的内容}
填写说明(学生按顺序完成):
- 用短句,不写长段;每个模块必须写“做什么/不做什么”。
- 接口字段必须可校验(必填/可选/枚举/范围);失败必须工程化(错误码、可重试性)。
- 每条关键数据流都要能回答:来源是什么?落在哪里?谁来用?如何回放?
工作表 1:模块划分卡(感知/决策/执行)
| 层级 | 子模块 | 做什么(职责) | 不做什么(边界) | 关键输入 | 关键输出 |
|---|---|---|---|---|---|
| 感知 | |||||
| 决策 | |||||
| 执行 |
工作表 2:架构图自检清单(画完必查)
| 检查项 | 通过标准(是/否) | 备注 |
|---|---|---|
| 系统边界清晰 | 内部模块与外部系统有边界线,数据流进出明确 | |
| 横切能力存在 | 权限、审计、trace_id贯穿、回放入口都有位置 | |
| 失败兜底可见 | 缺信息/冲突/超时/设备失败有路径或处理点 | |
| 模块不过载 | 单模块职责不超过3条,避免“万能模块” | |
| 可测试性说明 | 每层至少有1个可测试回归点(输入输出可复现) |
工作表 3:接口契约表(可落地)
| 模块 | 接口名 | 输入(字段:类型/约束) | 输出(字段:类型) | 错误码与可重试 | trace_id 与审计 |
|---|---|---|---|---|---|
| 感知 | |||||
| 决策 | |||||
| 执行 |
工作表 4:标注数据流图(从感知到决策)
要求:用“数据表/文件/事件流”的方式描述数据流,不要只写一句“进入训练”。
| 数据对象 | 来源(感知层) | 处理/标注 | 去向(决策层) | 追溯字段(必填) |
|---|---|---|---|---|
| 指令样本(raw_text) | trace_id / sample_id / ts_ms | |||
| 槽位标注(slots) | labeler_id / version | |||
| 意图标注(intent) | guideline_version | |||
| 规则命中(rule_hit) | rule_id |
- 你们上一讲写的智能体流程,如果增加一个新执行系统(例如换机械臂厂商),你要改哪里?为什么?
- 如果发生一次误控(动作下发错了),你如何复盘:是谁触发的、走了哪条决策、调用了哪个工具、参数是什么?
- 用工业级思路把“感知-决策-执行”拆成可交付模块,并画出一张可审计的架构图草案。
把“工业级”落到 6 条可检查原则(写在图上/表里,而不是只背概念):
- 边界清晰:每个模块写“做什么/不做什么”,避免职责漂移。
- 契约先行:先定义输入输出与失败语义,再写实现(避免后期接口反复返工)。
- 可回放:关键决策必须可回放(同样输入能复现同样路由/结果,至少在工程层面可解释)。
- 安全优先:执行层永远不“猜测执行”,权限不足宁可拒绝;高风险动作要二次确认或安全门禁。
- 可观测性:trace_id 贯穿感知→决策→执行→回执→日志;能从一次任务还原全链路。
- 绿色制造导向:减少无效调用与空转(例如重复解析/重复下发/无意义重试),提升一次成功率,降低能耗与停线风险。
-
感知层(数据采集与结构化)
-
指令采集:用户口语/文本指令
-
现场数据采集:分拣线状态、托盘/箱体信息、机械臂状态(可模拟)
-
解析与归一化:抽取槽位(物品/数量/目的地/优先级/约束),并做校验与单位统一
-
决策层(路由与规划)
-
意图识别:分拣下发/状态查询/规则查询/澄清提问/拒绝注入
-
规则匹配:把槽位映射到业务规则(目的地、禁混放、冷藏等)
-
任务规划:生成可执行动作序列(可包含:二次确认、分步执行、失败回滚)
-
异常处理:缺信息、冲突、注入干扰、工具失败、超时
-
执行层(控制与回执)
-
动作下发:把规划结果转为设备指令(或任务队列消息)
-
回执与状态:执行结果、失败原因、可重试性、当前状态查询
-
感知层负责“结构化与校验”,不要把业务规则塞进去。
-
决策层负责“选择与规划”,不要直接操作设备。
-
执行层负责“副作用与回执”,不要做复杂理解与推理。
-
用三条泳道:Perception / Decision / Action(或 感知/决策/执行)
-
线分两种:数据流(结构化对象)与控制流(调用/下发)
-
所有关键线都标注“数据对象名”(例如
PerceivedState、DecisionPlan、ActionReceipt) -
横切能力画成独立模块:AuthZ(权限)/ Audit(审计)/ Observability(可观测性)
示例架构图(Mermaid,可直接复制修改):
flowchart LR
subgraph P[感知层 Perception]
UI[用户/上位机指令] --> PARSE[指令解析与归一化]
SENS[现场数据采集] --> VALID[数据校验与融合]
PARSE --> STATE[结构化状态 PerceivedState]
VALID --> STATE
end
subgraph D[决策层 Decision]
STATE --> INTENT[意图识别 Intent]
INTENT --> RULES[规则匹配 RuleMatch]
RULES --> PLAN[任务规划 DecisionPlan]
INTENT -->|缺信息/冲突| CLARIFY[澄清/二次确认]
CLARIFY --> STATE
end
subgraph A[执行层 Action]
PLAN --> GATE[安全门禁/二次确认 Gate]
GATE --> DISPATCH[任务下发 Dispatch]
DISPATCH --> ROBOT[机械臂/输送线控制]
ROBOT --> RECEIPT[回执 ActionReceipt]
RECEIPT --> STATUS[状态查询/更新]
end
subgraph X[横切能力 Cross-cutting]
AUTHZ[权限校验 AuthZ]
AUDIT[审计日志 Audit Log]
OBS[可观测性 Trace/Metric]
end
UI -. trace_id .-> OBS
PARSE -. trace_id .-> OBS
PLAN -. trace_id .-> OBS
DISPATCH -. trace_id .-> OBS
AUTHZ --> GATE
PLAN --> AUTHZ
RECEIPT --> AUDIT
PLAN --> AUDIT逐段解释与自检:
PerceivedState / DecisionPlan / ActionReceipt是三段式的关键“交付物”,对应你们接口契约表里的输入输出对象。CLARIFY不是聊天装饰,它是“缺信息/冲突”分支的工程兜底:把问题问回去,更新PerceivedState再进入决策。AUTHZ与GATE体现工业场景安全底线:权限与门禁必须发生在执行前。OBS与AUDIT是可回放与可追责的基础设施:没它们就无法定位故障,也无法证明系统“按规则运行”。
- 把你们组的自选题场景(如苹果分拣)写成三段式模块清单(至少每段 2 个子模块)。
- 在架构图上标出三类失败点:缺信息、冲突、执行失败,并写出各自的兜底路径。
- 能画清系统边界、横切能力与数据对象名;
- 能说清每个模块“不做什么”;
- 能指出至少 3 个失败点与兜底位置。
快速检查(口头回答即可):
- 你们的
PerceivedState里有哪些字段?哪些字段缺失时必须澄清? - 你们的执行层如何回执?失败时怎么区分“可重试”与“需人工介入”?
PerceivedState:感知层输出(结构化状态)DecisionPlan:决策层输出(动作计划)ActionReceipt:执行层输出(回执与状态)
接口契约示例(Python 标准库 dataclass,便于阅读与自检):
from __future__ import annotations
from dataclasses import dataclass
from typing import Literal, Optional
Intent = Literal["dispatch_sort", "query_status", "query_rules", "clarify", "reject"]
Retryable = Literal["yes", "no"]
@dataclass(frozen=True)
class PerceivedState:
trace_id: str
raw_text: str
item: Optional[str]
quantity: Optional[int]
destination: Optional[str]
priority: Optional[Literal["low", "normal", "high"]]
constraints: tuple[str, ...]
missing_fields: tuple[str, ...]
@dataclass(frozen=True)
class DecisionPlan:
trace_id: str
intent: Intent
action_name: str
payload: dict
need_confirm: bool
@dataclass(frozen=True)
class ActionReceipt:
trace_id: str
ok: bool
status: Literal["accepted", "running", "done", "failed"]
error_code: Optional[str]
error_message: Optional[str]
retryable: Optional[Retryable]
逐段解释与自检:
-
trace_id必须在三种对象里都出现,用于全链路追踪与审计对齐(架构图里的横切能力要“落到字段”)。 -
missing_fields是感知层对“缺信息”分支的显式表达:决策层不靠猜测,而靠字段决定走clarify。 -
DecisionPlan.action_name/payload体现“决策层不直接控设备”:它只产出“要调用什么动作、带什么参数”。 -
ActionReceipt.retryable把失败工程化:上层可以决定“重试/降级/人工接管”,避免盲重试造成空转与能耗浪费。 -
E_MISSING_FIELDS:缺信息(应澄清,不应执行) -
E_CONFLICT:冲突(应二次确认) -
E_NOT_AUTHORIZED:权限不足(必须拒绝并审计) -
E_TOOL_TIMEOUT:工具超时(可重试或降级) -
E_DEVICE_FAILED:设备执行失败(多为需人工介入)
- 你先写:模块列表 + 关键数据对象名(不要空手让 AI 想象)
- 用 AI 生成:架构图 + 契约表初稿(模板 2/3)
- 人工审计:用“接口六问”和“架构图自检清单”找问题
- 迭代修订:把修改点写回到图与表(形成可交付版本)
建议你们把 AI 输出当作“可编辑草稿”,至少做 3 类审计:
- 可测试性审计:字段是否可校验?失败是否可复现?
- 安全审计:执行前是否有 AuthZ/Gate?高风险动作是否需要确认?
- 绿色审计:是否存在无意义循环/重复调用/盲重试导致空转?
在分拣智能体里,至少有两类标注数据:
- 感知层标注:从
raw_text标注出slots(item/quantity/destination/constraints) - 决策层标注:从
PerceivedState标注出intent与rule_hit(意图与规则命中)
推荐数据流图(Mermaid,可复制修改):
flowchart TB
subgraph P[感知层]
RAW[raw_text + sensor_snapshot] --> PS[PerceivedState]
end
subgraph L[标注与数据治理]
RAW --> QUEUE[样本入库 sample_store]
QUEUE --> LABEL1[槽位标注 slots]
QUEUE --> LABEL2[意图标注 intent]
LABEL1 --> DS1[dataset_slots_v*]
LABEL2 --> DS2[dataset_intent_v*]
end
subgraph D[决策层]
PS --> ROUTE[Intent Router]
ROUTE --> RULE[Rule Match]
end
DS1 -->|上线前/迭代| P
DS2 -->|上线前/迭代| D
subgraph A[执行层]
RULE --> ACT[Dispatch/Control]
ACT --> REC[ActionReceipt]
end
REC -->|回放/复盘| QUEUE逐段解释与自检:
sample_store是关键:把线上/演示的输入与结果(可脱敏)保存为样本,才能做回放、复盘与迭代。dataset_*_v*体现版本化:工业场景必须能说清“本次上线用的是哪一版标注规范与数据集”,否则难以追责与复现。ActionReceipt -> sample_store是闭环:把失败样本带回标注与训练,减少重复错误,降低返工与能耗。
可运行的最小“样本落盘”示例(标准库,不依赖第三方):
把下面代码保存为 sample_store_demo.py 后再运行。
import json
import time
import uuid
from pathlib import Path
def append_jsonl(path: Path, record: dict) -> None:
path.parent.mkdir(parents=True, exist_ok=True)
with path.open("a", encoding="utf-8") as f:
f.write(json.dumps(record, ensure_ascii=False) + "\n")
trace_id = str(uuid.uuid4())
record = {
"ts_ms": int(time.time() * 1000),
"trace_id": trace_id,
"raw_text": "把 3 个苹果放到 A 口,优先级高,注意易碎",
"sensor_snapshot": {"line": "L1", "robot_state": "idle"},
"perceived_state": {"item": "苹果", "quantity": 3, "destination": "A", "constraints": ["易碎"], "missing_fields": []},
"decision": {"intent": "dispatch_sort", "action_name": "dispatch_task", "payload": {"bin": "A", "item": "苹果", "qty": 3}},
"action_receipt": {"ok": True, "status": "accepted"}
}
append_jsonl(Path("data/sample_store/sorting_samples.jsonl"), record)
print("saved:", trace_id)
逐段解释与自检:
trace_id必须写入样本:用于把“指令—决策—执行回执”串成一条证据链。ensure_ascii=False保证中文不被转义,便于阅读与人工抽检。
对应运行命令(PowerShell / CMD 均可,示例按 PowerShell 书写):
python -c "import sys; print(sys.version)"
python sample_store_demo.py
逐条解释与自检:
- 第 1 行确认 Python 可用,避免把环境问题误判成代码问题。
- 第 2 行运行示例脚本;运行后应输出
saved: <trace_id>,并在data/sample_store/下生成sorting_samples.jsonl。
- 为你们的自选题场景补齐一份接口契约表(至少 6 行接口)。
- 绘制一张标注数据流图,并明确:样本从哪里来、标注产物去哪里、版本怎么写、trace_id 如何贯穿。
- 契约表能支撑实现与测试(字段可校验、错误码可用、可重试性清晰)。
- 数据流图能形成闭环(线上样本 → 标注 → 数据集版本 → 迭代 → 回放)。
工业级 AI 智能体架构不仅关乎“能用”,更关乎“绿色、可靠、可持续”:
- 通过合理架构减少无效执行与重复调用,提高一次成功率,降低设备空转与能耗浪费。
- 通过可回放、可审计的证据链减少“甩锅式排障”,缩短停线时间,提升整体效率。
- 通过最小权限与安全门禁降低误控风险,保护人员与设备安全,体现工程伦理与社会责任。
- 学习智能体架构设计原则与模块划分方法,完成工作表 1/2/3/4。
- 结合分拣/自选题场景,梳理“感知 - 决策 - 执行”各模块的功能与边界,绘制架构草图(建议 Mermaid 或手绘拍照)。
- 使用 AI 大模型生成架构设计初稿,进行人工审计并优化模块接口设计,记录修改点与理由。
- 梳理数据标注环节在架构中的数据流,绘制简单数据流图(要求含版本与 trace_id)。
-
架构图包含三段式、横切能力与至少 3 条失败兜底;
-
接口契约表至少 6 行,含错误码与可重试性;
-
数据流图能说明标注产物如何被决策层使用。
-
生成工业级 AI 智能体架构设计原则思维导图(模板 1)。
-
结合分拣/苹果分拣场景生成参考架构方案(模块划分 + 接口定义)(模板 2/3)。
-
辅助审计学生架构图,指出接口设计问题并给改进建议(模板 4)。
-
讲解标注数据流在架构中的设计要点,并生成可复用的数据对象清单与版本策略。
作业(布置)
1)提交自选题场景的 AI 智能体架构图(含模块划分、接口定义),附架构设计说明(200 字左右,阐述模块划分依据)。
2)提交 AI 交互记录(生成架构初稿、优化接口设计的全过程),撰写 100 字左右说明,描述对 AI 生成内容的调整思路。
3)梳理数据标注环节在架构中的数据流,绘制简单的数据流图(要求包含样本来源、标注产物、数据集版本与 trace_id 贯穿)。
提交检查清单(提交前自检):
- 架构图:系统边界清晰、横切能力落位、失败兜底可见、数据对象命名一致。
- 契约表:字段可校验、错误码工程化、可重试性明确、trace_id 贯穿。
- AI 记录:能看出“初稿 → 审计 → 修订”的过程,不是一次性生成。